Lookerベスト・プラクティス：Lookerパフォーマンスの最適化 #looker

「カスタマーストーリー」を支えるツール特集

#ビッグデータ

#ビジネス・アナリティクス

#Looker

しんや

2019.09.30

この記事は公開されてから1年以上経過しています。情報が古い可能性がありますので、ご注意ください。

Lookerではトピック毎のベストプラクティスを個別にドキュメントやナレッジベースとしてまとめています。当エントリではその中から、『Lookerパフォーマンスの最適化』についてご紹介したいと思います。

Best Practice: Optimize Looker Performance – Looker Help Center

クエリパフォーマンス

まずはじめに「クエリパフォーマンス」に関するトピックから。LookerではLookML上で設定を行い、その設定でSQLクエリを構成し、実行します。そのクエリに関するポイント群をご紹介します。

結合(Join)にはmany_to_oneを使う

可能な限り、many_to_one結合を使ってエクスプローラ(Explore)を構築するようにしてください。ビュー同士をこの形(many_to_one)で結合することで、より良いクエリパフォーマンスが得られるようになります。

many_to_one (the default value) - relationship

キャッシュの活用

キャッシュを最大化し、可能な限りETLポリシーと同期させてデータベースへのクエリ発行トラフィックを削減しましょう。初期設定では、Lookerはクエリを1時間キャッシュします。persist_withパラメータを使い、エクスプローラ(Explore)内でdatagroupsを適用させることで、対象のキャッシュポリシーを制御し、Lookerのデータ更新とETLプロセスを同期させることが出来ます。

この設定により、Lookerはバックエンドのデータパイプラインとより緊密に統合が出来るようになり、古いデータを分析するリスク無しにキャッシュ使用を最大限活用可能となります。名前つきキャッシュポリシーはモデル全体に適用したり、個々のエクスプローラや永続派生テーブル(PDT)に適用出来ます。

クエリの高速化に永続派生テーブル(PDT)を使う

クエリを高速化するには、PDTを使います。

ビューを事前に結合し、実行前に準備しておけるように、多くの複雑な結合やパフォーマンスの低い結合を含むエクスプローラはPDTに変換しておきましょう。

エクスプローラ(Explore)での結合について

Lookerで定義されている連結されたprimary_keysで、ビュー(View)をエクスプローラ(Explore)に結合しないでください。

primary_key

代わりに、ビュー(View)のベースフィールド(連結されていないフィールド)で結合するか、ビューのLookMLでは無くテーブルのSQL定義で事前に定義された主キーを使用してビューを永続派生テーブル(PDT)として再作成します。

ダッシュボードの自動更新機能を活用

ダッシュボードの自動更新機能を戦略的に活用してください。

Dashboard Auto Refresh - Editing User-Defined Dashboards

この機能を使う場合、バックグラウンドで実行されているETLプロセスが終了するタイミングよりも早く実行しないように注意してください。

Lookerサーバパフォーマンス

次いで「Lookerサーバパフォーマンス」について。Lookerでは『データをLooker側に持ってこない』という大前提があるので、基本的には『データベース側で何とかする』スタンスではあります。ですがLookerの諸要素の構成における設定を見直すことで、結果としてパフォーマンス向上に繋がります。後半ではそれらのポイントについてご紹介します。

ダッシュボードの要素数を見直す

個々のダッシュボードにおける、要素の数を制限しましょう。

各要素の設計は様々な要因に基づいてメモリ消費に影響を与えるので、一概に「これだ！」という厳密なルールはありませんが、25個以上のタイルを含むダッシュボードはパフォーマンスに関して問題を多く含む傾向にあります。

ピボット(Pivot)の多用を避ける

ダッシュボードのタイルとLook内では、ピボット(Pivot)を使いすぎないように気を付けましょう。

ディメンションの並べ替え - Lookerでのデータ探索

ピボット(Pivot)されたディメンションを持つクエリは、より多くのメモリを消費します。結果として、そういう要素が多いダッシュボードほど、ロード時に多くのメモリを消費してしまい、結果としてパフォーマンス悪化を招きます。ピボット(Pivot)は使いどころを考えて戦略的に使用しましょう。

モデルに含めるビューの数を制限する

多数のビューが存在している場合、モデル(Model)に含まれるビュー(View)の数を制限しましょう。

全てのビュー(View)を単一のモデル(Model)に含めてしまうと、パフォーマンス低下を招く可能性があります。各モデル(Model)に必要なビュー(View)ファイルのみを含めることを検討してください。また合わせて、モデル(Model)内にビューのグループを簡単に含めることが出来るように、ビューファイル名に戦略的な命名規則を使用することを検討してください。

Things to Know - include

データ件数もなるべく少なく

ダッシュボードタイルやLook内に、大量のデータ件数を返すようなことも避けてください。大量のデータを返すクエリはそのまま、より多くのメモリ消費にも繋がります。以下の機能を使い、可能な限りデータ件数を制限してください。

フロントエンドフィルタの機能をダッシュボード、ビュー、エクスプローラに適用
- Adding Dashboard Filters a User Can Change - Adding Filters to User-Defined Dashboards
LookMLレベルで以下の機能を活用

まとめ

というわけで、Lookerにおける『Lookerパフォーマンスの最適化』のご紹介でした。

利用ユーザーや利用頻度が増えてくるに従い、求められるパフォーマンスや性能も変わってきます。この点はLookerに於いても他のBIツールやデータ分析環境と変わりません。『より負荷の掛からない構成、設定』『要素数やデータ件数は少ないに越したことは無い』といった部分ですね。快適かつスムーズな分析・可視化ライフを送れるように、当エントリで紹介した内容を踏まえて適切にLooker環境をメンテナンスして行きましょう！